Casper CBC: Message validation

Description

Roughly speaking, message validation process might be divided as two parts in the followings.

References

What methods are nessesary to validate message, state and estimate?

Invalid Block

Does not contain the correct fields.

The estimate is not justified (with weight from the senders view)

New_messages's justification lies about what has been seen (e.g. justification must be at least as recent as the previous justification from validator).

Justification contains two messages from one validator, as if there as an equivocation, but these messages are not an equivocation!

Two messages justifications contain messages that should be equivocations, but the sender of these two messages didn't notice they were.

Make a decision on a block that is not in forkchoice.

An equivocation:

Two blocks from the same sender with the same sequence number

Two blocks from the same sender where there is not a clear order between the two protocol states attested to by the justifications.

Note that some of these require the entire justification of the message to be seen before this can be detected. Thus, it likely makes sense there are some "initial quality checks:" message is a block and contains the correct fields (maybe a bit of PoW ;) ). Then, when the justification for the message arrives, the second round of quality checks occur.

This likely should occur in the node, and then it is passed to the validator's view as either a) an equivocation, b) an invalid block, or c) a good block to add! The response in these three cases should be different (e.g. updating forkchoice weights to 0 if a, b), and the view needs additional structure to support these types of messages.

For some protocols, checking that an estimate is valid requires walking from some previous block (or set of outputs) in the past. For example, this is the last_finalized_block in TGF. However, this is not currently included in messages.

Nodes generating invalid messages is also a fairly easy, but broad, class of faults to understand. For example, if we are running a CBC Casper binary consensus protocol (where nodes are coming to consensus on either a 0 or 1), if a node makes a message the estimate 2, this is clearly invalid. There are other types of invalid messages that are more interesting than the above example that we will expand on later in the FAQ.

Equivocation is probably the most interesting of the possible faults. Essentially, a node is equivocating if it's running two copies of the consensus protocol that are unaware of each other, at the same time. For example, if a validator simultaneously makes two messages, one with an estimate of 0 and another the estimate 1 (where neither message acknowledges the existence of the other message), we say this validator is equivocating. Clearly, this type of behavior is bad when we are trying to get nodes to come to agreement on a value.

Some optimizations?

Ok so currently the python codebase doesn't actually check that messages are valid / not equivocations

but for binary consensus, this actually shouldn't be to bad. One optimization that the python codebase does that is def worth doing is adding a sequenceNumber or similar field to the messages